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Abstract. We present tiie concept of a unified grapliical environment 
for expressing tiie semantics of control systems. The graphical control 
system design environment in Simulink already allows engineers to in- 
sert a variety of assertions aimed the verification and validation of the 
control software. We propose extensions to a Simulink-like environment's 
annotation capabilities to include formal control system stability, perfor- 
mance properties and their proofs. We provide a conceptual description 
of a tool, that takes in a Simulink-like diagram of the control system as 
the input, and generates a graphically annotated control system diagram 
as the output. The annotations can either be inserted by the user or gen- 
erated automatically by a third party control analysis software such as 
IQC/3 or /i-tool. We finally describe how the graphical representation of 
the system and its properties can be translated to annotated programs 
in a programming language used in verification and validation such as 
Lustre or C. 



1 Introduction 

Embedded control systems are ubiquitous in present day safety-critical applica- 
tions. The aerospace and medical fields are filled with examples of such systems. 
The verification and validation (V&V) of their software implementation has al- 
ways been a major preoccupation given the dire consequences of any potential 
malfunction. It has been the endeavor of the formal methods community to pro- 
vide tools that facilitate and rationalize this process. However, currently there is 
little communication between the engineers who design the control system and 
the engineers who do the V&V. It has been noted in [5] that the former could 
potentially provide valuable inputs for the latter in regards to finding the rele- 
vant invariants. We believe that inputs from the control engineer can be helpful 
to the V&V community if the following can be provided: 
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— An environment for the control engineers to easily insert stability and per- 
formance proofs into their designs. 

— Automatic translation of the information provided by the control engineers 
into a form that is familiar to the V&V community. 

In this paper, we present an extension to the current block diagram represen- 
tations of control systems (Simulink, Xcos) that include fundamental control 
systems proof information such as a Lyapunov function, which establishes sta- 
bility, and the plant model with respect to which stability was established at the 
time the controller was designed. These extensions resemble, but are different 
from, Simulink's current diagram annotation capability. 

1.1 Challenges 

The following are the challenges that we like to address: 

— Provide a coherent set of new blocks in a Simulink-like environment that 

enable a wide array of systems and types of stability proofs to be handled. 

— Provide a formal semantics for the new graphical environment. The seman- 
tics can be inherited from a Simulink-like environment that has a formal 
semantics such as Scadc. 

— Develop a tool to perform translation from the Simulink-like environment to 
an industrial programming language such as Lustre or C. 

1.2 Background 

Simulink being the de-facto industry tool for embedded controllers, has been the 
subject of many research efforts in the validation and verification community. 
There have been numerous attempts at the translation of Simulink into other 
languages for the purpose of formal analysis. See [1], [10], [2] and [12]. The ideas 
presented in this paper are not specifically confined to Simulink, but rather they 
form an overall concept that can be implemented in any graphical modeling 
language tool. This work is closely related to the ideas presented in [5], as it 
explores autocoding with proof at the interface with the control engineer. 

2 Conceptual Overview 

We begin by proposing a tool represented by the illustration in figure 1. The 
front-end of the tool provides a unified graphical environment for the design 
of control systems as well as the insertion of proofs about the control systems. 
The back-end translates the visual design with proofs into annotated code in 
an industrial programming language, such as Lustre or C which can then be 
analyzed using V&V tools developed by the formal methods community. We 
describe the top-level components that make up the tool with the focus on 
the graphical environment for the expression of control systems semantics. The 
demonstrations in this paper use existing annotative capabilities of the graphical 
modeling platform Simulink. 



Input: Controller design in the simulink language 
Output: annotated code in Lustre or C 
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Fig. 1. Overall Picture 



2.1 Front-end 



The front-end of the tool takes in an input of a Simulink-like model and feeds to 
the verification block generator (the green block in figure 1 ). Let us consider the 
model of the double integrator system in figure 2 as the input. The verification 
block generator produces an output model that includes additional blocks and 
wires (see the red portion in figure 3), which are arranged to express an asser- 
tion on the states of the input model. The Simulink environment gives the user 
great flexibility in expressing a variety of stability and performance criteria from 
control theory literature. In this particular example the verification block checks 
the stability of the double integrator system in the presence of a noise that is 
bounded in power. However, note that the stability proof annotation in figure 
3 was constructed by concatenating two signals together, and then feeding the 
output through several mathematical and logic blocks from the Simulink library. 
This can become a very cumbersome process to the control engineer. To simplify 
this as much as possible we propose an extension to the current Simulink block 
library to allow a more direct way of expressing control systems properties and 
their proofs. For example the bounded noise stability property in figure 3 can 
be captured more succinctly by a new annotation block type denoted stability 
with the following three parameters: the positive-definite matrix P, the charac- 
teristics of the noise input and the states of the control system. More examples 
and detailed descriptions of the variety of control systems properties and proofs 
can be found in section 3. 
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Fig. 2. Model Input 
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Fig. 3. Verification Block Generator Output 



2.2 Automatic Generation of Control System Proofs 

The most important parameter in the proposed stability block type is the positive- 
definite matrix P since stability proofs for many control systems boils down to 
computing this matrix [4], and the proof flows down to the code-level in a nice 
fashion [5] . To automate this process as much as possible we propose linking the 
verification block generator with automatic control system analysis tools (see the 
pink block in figure 1). Several third party tools exist which can adapted for this 
role. For linear control systems the P can always be generated automatically by 
a robust control toolbox such as the IQC/3 or /i-tool (see [9], [11] and [3]). For 
nonlinear control systems such as adaptive controllers it is likely that manual 
input will be needed. For example the user might be expected to insert the Lya- 
punov function by using the appropriate Simulink blocks and connecting them 
with the wires. For these cases where the automation fails, the model output 
from the verification block generator is provided to the user as the interface for 
the manual insertions of the stability proofs (see the gray block in figure 1). 

2.3 Formalism 

We propose a new type of wire that elevates signals to the abstract level to 
allow easy differentiation between signals that represent the states of the control 
system i.e. x(t) in figure 3 and signals that are not the states of the control 
system. The rest of the newly proposed annotation block types can use the 
existing blocks and wires structure, with some indication that they are not to be 
used for code generation, but for annotation generation. For this we also propose 
an intermediate language representation of the Simulink model that makes this 
distinction clearly. The existing labeling options that exist in Simulink can be 
useful here to keep track of names. 

2.4 Back-end 

The back-end of the tool is the translator from the graphical environment to a 
programming language such as C or Lustre. The majority of work here is will be 
formalizing the semantics of the graphical environment. The translation process 
must also deal with time discretization of the stability proof annotations, which 
can be quite difficult depending on the type of control system that the user put 
into the tool. 

3 Simulink Examples 

Wc present several examples of annotating stability proofs and performance 
criteria for control systems in the Simulink enviromncnt. These examples can 
obtained from control engineering books such as [8] or [6] . 



3.1 Semantics of the Simulink blocks and wires 



The mathematical operational blocks such as sum, multiply, divide, dot prod- 
uct are polymorphic just like every other Simulink blocks. They take input ar- 
guments of many different types: scalar, vector of arbitrary dimensions, and 
matrices. Semantically the blocks can change either due to different input argu- 
ments or user specification. For example the "Product" block can be a product 
of scalars, matrix multiplication, or clement-wise multiplication of the entries 
of the vector depending on the input argument and user choice. The wires can 
carry all numerical data types available in Simulink. The two relevant types in 
the control system diagrams are scalars and vectors that are assumed to be cither 
real or complex. For expressing most annotations of stability proofs and perfor- 
mance criteria, we can use the existing blocks in Simulink. A small amount of 
annotations may require the convenience of functions defined outside of Simulink 
environment i.e. MATLAB for example. 

3.2 Lyapunov Stability 

We start with Lyapunov stability, since it is the simplest stability result in time- 
domain that we can express using the graphical environment of Simulink. The 
essential part of the Lyapunov stability is the quadratic Lyapunov function V{x) 
in (1) where x is the state of the control system and P is a positive-definite 
matrix. 

V{x) = x'^Px (1) 

The noise block is set to 0. The verification block shown in figure 4 expresses the 
following assertion: the lie derivative of the Lyapunov function V{x{t)) is less 
than or equal to zero. The matrix P can be computed using either one of the 
two robust control toolboxes mentioned. 

3.3 £2 Gain Stability 

For input-to-output stability, the annotation diagram becomes more complex. 
In this case both the storage and supply functions need to be constructed [6]. 
Figure 5 has an example of a proof annotation showing finite £2-gain stability of 
the double integrator system. The annotation expresses the following assertion: 

V{x) - a'^w^w + y^y < (2) 

where w is the unit-peak uniform noise input, V{x) = x^Px is a quadratic 
Lyapunov-like function called the storage function, and y is the output signal. 

The proposed extensions to the interface will reduce drastically the number of 
blocks and wires necessary to construct this stability proof annotation. Despite 
the increase in complexity one of the essential component of the annotation is 
still a positive-definite matrix P. This P can also be obtained using the two 
robust control solvers mentioned in section 2, therefore the diagram in figure 5 
can be generated automatically. 
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Fig. 4. Lyapunov Stability 



3.4 Plant Model as Annotation 



Most controller stability proofs are based on some form of model for the plant 
that is being controlled. Thus the plant needs to be introduced somehow in the 
annotation framework. This is actually relatively straightforward at the graphical 
level, since most graphical modeling tools are not only meant for implementing 
controllers, but also for testing them, and in the latter case a model for the 
plant must be present. Figure 6 shows how we go about displaying plant model 
information at an abstract level, which will not interfere with the executable 
code that will be generated. We take the example of the following plant from [7] 

mx + ci (x^ — C2) X + [ki + ^22^^) X = u (3) 
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Fig. 5. Finite Gain £2 Stable 



The Lyapunov stability of the feedback interconnection of the plant and the 
controller is established by the Lyapunov function 
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This complex example is mainly introduced to show the almost unlimited 
expressive power of the proposed interface extension. 



3.5 £1 Adaptive Controller Performance 

To further demonstrate the expressive power of the graphical environment, we 
show the following £1 adaptive controllers (see figure 7) and an example of an- 
notating a performance bound. For L\ controllers there exists a proof of not only 
closed-loop Lyapunov stability but also bounds on the transient performances. 
For example the bound on the state prediction error x of the controller is a func- 
tion of the uncertainty of the plant "theta_max", the Lyapunov function matrix 
P and the adaptive gain "Gamma". Note that the uncertainty parameter of 




Fig. 6. Adaptive controller with Plant 
plant can be part of the plant model or separate by itself as in figure 7 



3.6 Discretization during Translation 

Thus far we have shown several examples of continuous-time proofs of stability 
for control systems. Now how do these proofs translate down to the code-level? 
The main issue as mentioned before is the time-discretization that is applied to 
the model when it is translated into code. Fortunately for all linear control sys- 
tems, the discrete-time stability proofs can be easily and systematically obtained 
However for the adaptive controllers, it is very impractical to look for Lyapunov 
stability proofs in discrete-time hence the problem remains that we must use the 
continuous-time proofs as invariants for the discretized system. 

4 Integration with Third Party Tools 

For the integration of third party control system analysis tools, we'll need to 
build a component that extracts the necessary control system parameters and 
characteristics from the input Simulink model. For this procedure to be auto- 
mated it is again necessary to have a formal semantics of the proposed graphi- 
cal environment. System information such as the state-space model, the system 
states, the input noise disturbance are examples of the required inputs needed 
for IQC/3 and /z-tool. 
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Fig. 7. Ci Transient Performance Bound 



5 Conclusion and Future Work 



In this paper we have proposed a new graphical environment that ahows the 
easy expression of the semantics of computer-controlled systems. We believe this 
environment simplifies the process by which the control engineer can provide do- 
main knowledge for the deductive verification of the controller implementation. 
We have provided several examples of how control stability proofs and perfor- 
mance criteria can be expressed in a current graphical modeling environment 
i.e. Simulink. For the new graphical environment, we have proposed several ex- 
tensions designed to enhance the proof annotative capabilities of the current 
environment. We are currently in the process of formalizing the new unified 
graphical environment. This is a proposed research orientation that still requires 
much effort: formalizing the graphical annotation "language", integrating it in 
an existing graphical modeling environment, interfacing it with third party tools, 
and lastly implementing the translation tool that will generate the annotated 
code from the extended diagrams. 
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